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Abstract 

Discrete event simulation specification (DEVS) is a formal- 
ism designed to describe both discrete state and continuous 
state systems. It is a powerful abstract mathematical nota- 
tion. However, until recently it lacked proper graphical rep- 
resentation, which made computer simulation of DEVS mod- 
els a challenging issue. Unified modeling language (UML) is 
a multipurpose graphical modeling language, a de-facto in- 
dustrial modeling standard. There exist several commercial 
and open-source UML editors and code generators. Most of 
them can save UML models in XML-based XMI files ready 
for further automated processing. In this paper, we propose 
a mapping of DEVS models onto UML state and component 
diagrams. This mapping may lead to an eventual unification 
of the two modeling formalisms, combining the abstractness 
of DEVS and expressive power and "computer friendliness" 
of the UML. 



1. INTRODUCTION 

Discrete event simulation specification (DEVS [11]— [13]) 
is a powerful formalism for describing discrete event state sys- 
tems. Various flavors of this formalism have been developed. 
In this paper, we are using classic DEVS with ports, which 
we call, simply, DEVS. 

Being hierarchical and encapsulated, the DEVS formal- 
ism can be naturally implemented in an object-oriented lan- 
guage, such as Java [9]. However, Java-based simulation en- 
vironments have never been standardized (unlike the DEVS 
formalism) . 

An important drawback of the DEVS formalism is the 
lack of a standardized graphics representation. In [2], an at- 
tempt has been undertaken to develop DCharts, a graphics 
language for DEVS models. DCharts is a UML-based lan- 
guage; however, it does not strictly follow any UML standard. 
Moreover, the DEVS-to-DCharts transformation proposed 
in [2] collapses all DEVS states into one DCharts state, essen- 
tially eliminating the discrete state nature of DEVS models. 

In [5], it is proposed that atomic DEVS models be rep- 
resented with the help of UML sequence diagrams. However, 
the sequence diagrams show actual, rather than potential, 
flow of events. Because of this, a sequence diagram is limited 
to a particular scenario and cannot unambiguously describe 
the behavior of a system in its entirety. 

An excellent mapping between DEVS models and UML 
state charts has been introduced in [10]. However, the paper 
does not suggest a formal mathematical way of constructing 
the state charts, and thus avoids the issue of the structural 
clash between DEVS continuous states and UML finite states. 



It also relies on the older versions of the UML (< 2.0), which 
did not have an explicit notion of time. 

In this paper, we propose a consistent DEVS-to-UML 
mapping that takes care of all issues mentioned above. Fur- 
ther restricting the mapping to the executable UML (which 
is a proper subset of UML [7] ) would make a seamless connec- 
tion between a DEVS model and an UML simulation process, 
but this topic is beyond the scope of this paper. 

2. DEVS FORMALISM 

DEVS supports two complementary models of describing 
discrete systems: an atomic model that specifies the behavior 
of an elementary system, and a coupled model that allows us 
to form more complex models by structurally interconnecting 
atomic and other coupled models. 

A DEVS atomic model is a state machine with input 
ports IP = {ttI"} and output ports OP = {n° ut }. Events 
are associated with input and output ports (they happen at 
input ports and are generated at output ports). In general, 
states, unlike events, are not discrete. 

2.1. Atomic Models 

Atomic DEVS model M a is a tuple of nine values M a = 
{IP, OP, X, E, Y, Sin, <5ext, A, t }. Here, IP and OP are sets of 
input and output ports. 

E is a set of states {en}. A DEVS state Oi is uniquely 
identified with a set of state variables 7i = 7^ <Jk 

3j : Hi 

A is a set of input events {xi — (irj™, vA}, where n 1 ™ 6 
IP is the port name, and Vi is the event value. Every event 
has an associated timestamp, or scheduled time — the time 
when the event is triggered. 

Y is a set of output events {yi — 0K° ut , u*)}, where 
n° ut £ OP is the port name, or the event type, and Vi is 
the event value. 5- m t (<7j) : E — > E is the internal transition 
function. <5 cx t (at, et,Xj) : (E x R x IP) — > E is the external 
transition function, where e, is the elapsed time in state rn. 
A (<Tj) : E — > Y is the output function. t a : E — > R is the 
time advance function. 

The semantics of the model are as follows: the system 
stays in state at for t a (at) time units (until a timeout event) 
or until an external event happens, whatever comes first. 
In the case of an external event Xj, the system changes its 
state to 5ext (fi, et,Xj). In the case of a timeout, the sys- 
tem changes its state to <5i n t (ct,) and generates an event of 
type A(<7i). In either case, the simulation time is implic- 
itly advanced to the timestamp of the event that triggered 
the transition. The initial state of the model is not defined 
explicitly. 



2.2. Coupled Models 

Coupled models are used to compose atomic and other 
coupled models to produce more DEVS models in a hierar- 
chical way (Figure 1). 
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Figure 1. Atomic and coupled DEVS models 

Coupled DEVS model TV is a tuple of ten values TV = 
{IP, OP, X, Y, D, M, Eic, Eoc, Ic, S}. Here, IP and OP are 
sets of external (not coupled) input and output ports. X is 
a set of input events Xi = yn\ n , Vij, where irl" £ IP is the 
port name, and Vi is the event value, and Y is a set of output 
events %ji = (7r°"*, vi), where -K° ut £ OP is the port name, 
and Vi is the event value. 

D = {di} is a set of references to the coupled compo- 
nents (atomic models or other coupled models), and M — 
{Md\d £ D} is a set of the coupled components. Eic C 
{((N,IPi),(d,IP di ))\lPi £ IP,d £ D,IP d » £ IP d } is exter- 
nal input coupling that connects external input ports of the 
coupled model to the components' input ports IPd- Eoc Q 
{(d,OP di ),((A r ,OP ! ))|OP I £ OP,d £ AOP dl G OP d } is 
external output coupling that connects components' output 
ports OPd to the external output ports of the coupled model. 

Ic = {{(a,OP al ),{b,IP b:j ))\a,b £ D,OP al £ 
OP a ,IP;,j £ IP;,} is internal coupling that interconnects 
output and input ports of the components. Finally, S : 
{ed\d £ D} — > ed is a selection function that resolves potential 
scheduling conflicts, when more than one event in different 
components has the same scheduled time. 

Under the principle of closure, a coupled model looks 
externally like an atomic model and can be used anywhere in 
place of an atomic model. 

A coupled model is simulated as an ensemble of its DEVS 
components. Output events generated by each individual 
component are propagated to the input ports of other coupled 
components or to the output ports of the model, according 
to the functions Ic and Eoc- In the former case, they are 
also converted into appropriate input events. Input events 
received by the model are propagated to the input ports of 
its components, according to the function Eic- 

Classic DEVS formalism does not permit feedback loops: 
((<*, OP di ), (e, OP e3 )) £ Ic => d + e. 

3. UML FORMALISM 

The Unified Modeling Language (UML [1]), a de-facto 
industrial modeling standard, seems to be a natural choice 
for a visual representation of DEVS. Besides being widely 
supported by both proprietary and open-source tools (such 
as Rose [6] and Poseidon [3] ) , it also has an associated XML- 
based representation, XMI, that makes it possible to process 
UML diagrams by application programs. 

Of particular interest for us are UML state and compo- 
nent diagrams, which will be discussed in detail. 



3.1. State Diagrams 

A UML state diagram (also known as a statechart, Fig- 
ure 2) is a visual representation of a finite state automaton 
with history. Many of the features of state diagrams, such 
as "do" activities, history states, junction and choice states, 
concurrent and composite states, are not essential for DEVS- 
to-UML mappings and will not be considered. 
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Figure 2. A UML state diagram 

A state diagram is a tuple SD = {S, S', S 10 , P, T}. 
Here S = {s; = (Gi,Wi,qi)} is a set of finite states. UML 
finite states are enumerated using state variable G, such that 



Si — Sj Gi — Gj 



i(x) : any — » None is an "entry" ac- 



tion. This action is executed just after changing the current 
state of the model to Si. Qi(x) : any — > None is an "exit" ac- 
tion. This action is executed just before changing the current 
state of the model from Si to some other state. 

A set of possibly continuous pseudostate variables H — 
{hk} (\H\ > 0) extends the definition of a UML state. The 
pseudostate variables may or may not have different values 
in different states. They cannot be used to distinguish UML 
states in a state diagram. An optional class diagram of the 
UML system can be used to record these variables in the 
model (Figure 3). 



AtomicModel 



+ gamma_1 :int 
+ gamma_2 :double 



Figure 3. A UML class diagram that consists of only one 
class definition. Notice that, formally, variables of types int 
and double are finite, because both classes have limited 
range and cardinality. 

5" = {si £ S} is the set of the initial states of the 
diagram. Every diagram can have at most one initial state. 
Because DEVS formalism does not specify the initial state of 
the system, we will assume that in general S' = 0. 

S® = {si £ S} is the set final (terminal) states of the 
diagram. Because the final state of a DEVS system is not 
defined, we will assume that in general S® = 0. 

P — {pj} is a set of discrete events. Each event pj has 
the associated scheduled time Tj and a possibly empty set of 
other attributes. 



Finally, T= {s bi , s e i,Pi, gi,di\su, s ei G S,p t G P,gt (x) : 
range(a;) — > {True, False}, ai(y) : any — » None} is a set of 
transitions. In UML notation, a transition from state s Di to 
state s e i on event pi with guard condition gt is denoted as 
Pi [gi] I at . Action ai is executed just before the completion of 
the transition. The action is not allowed to change the UML 
state of the system. 

The semantics of a UML state diagram prescribes that 
in the course of transition ti from state Sj to state Sk the 
"exit" action qj is executed first, followed by the transition 
action at, followed by the "entry" action Wk- 

3.2. Component Diagrams 

UML component diagrams have evolved substantially 
from version 1.x of the language to the current 2.0 [1], [8]. 
The direction of the evolution has favored the DEVS-to-UML 
mapping we are about to propose. 

In the latest version of the language, deployment, ob- 
ject, and component diagrams have been merged into a sin- 
gle class of deployment/object/component (DOC) diagrams. 
These new DOC diagrams have a rich language suitable for 
elaborated models, but for the purpose of this paper we need 
to mention only components, interfaces, and ports. 
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Figure 4. A UML component diagram 

A UML component diagram is a tuple TV" = 
{M",Q«, 

Here, M u — {M™} is a list of components in the 
diagram. Each component M" has list P" = {pij = 
(tij,ifij ,dij)} of externally visible ports. A UML port p 
has a type. The type of the port specifies the names of 
the signals (events) that are acceptable through this port. 
For the purpose of this paper, we assume that the type t of 
the port is the same as its name. A port can be unidirec- 
tional (input or output) or bidirectional. The direction of 
the port dir(pij) is defined by the type(s) of its interfaces. 
Since DEVS formalism does not support bidirectional ports, 
we will not consider them and consider only one interface 
K = (n, d) per port, where n is the name of the interface and 
d — { required j provided} is its type. Required interfaces ("an- 
tennas") define output ports, and provided interfaces ("lol- 
lipops" ) define input ports. 

A UML component represents either another UML com- 
ponent diagram, or a UML state diagram. 

Set Q u C {(M?,M?)\M? C M u A MJ C M"} defines 
the containment relation: component M is a subcomponent 
of component TV, or a nested component, if (TV, M) G Q u . 
Let Z(TV) = {Mi\Mi G M u A ((N,Mi) eQ"V (3Mj : Mj G 



Z(N) A (Mi, Mi) G Q u )} be the set of children of TV. The 
containment relation must satisfy additional conditions: (a) 
a component cannot be a subcomponent of itself: VM G M u : 
(M, M) Q u and (b) if M is a subcomponent of component 
TV, then TV cannot be a subcomponent of M or of any child of 
M : (TV, M) £Q"« (M, TV) Q u AVAf G Z(M) : (M',N) <£ 

Components Tat- = {Ti\Ti G M u A VM G M u : 
(Ti,M) £ Q u } are called top-level components. The set: 



E u c C {((Mi,pik),Mj,pji))\ 
Mi G M n A Mj G M U A 
(Mi, Mj) G Q U A 
Pik G P? A p 3i G P"A 
dir(pi fe ) = &\r(pji)} 



(1) 



is the external coupling that connects external ports of the 
component to the subcomponents' ports using UML delega- 
tion connectors. External ports must be connected to the 
internal ports of the same direction. The set: 



Ic Q {((Mi, Pik), (Mj,pji))\ 
Mi G M u A Mj G M U A 
3M P G M u : {(Mi,M p ), (Mj,M p )} C 
Pik G Pi A pji G P/A 
dir(p ife ) / dir(p i; )} 



(2) 



is the internal coupling that interconnects ports of the sub- 
components of the same component using UML assembly con- 
nectors. Internal ports must be connected to the internal 
ports of the opposite direction. Graphically, this is accom- 
plished by matching "antennas" and "lollipops" . 

A simple UML component diagram (strictly speaking, a 
DOC diagram) is shown in Figure 4. It depicts two compo- 
nents Ml and M2. These components are in turn subcompo- 
nents of component A. Component A has two output ports 
ElOut and E20ut with interface ISend and one input port 
E3In with interface IRcv. The output ports of subcompo- 
nents Ml and M2 are connected to the corresponding output 
ports of the component A, the input port of A is connected to 
the input port of subcomponent Ml. Finally, the output port 
E40ut of component Ml with interface ISend is connected to 
the input port E4In of component M2 with interface IRcv. 

Composite structure diagrams, which only recently have 
become a part of the UML 2.0 proposal [4], offer even better 
mapping between DEVS models and UML models. However, 
the discussion of these diagrams is beyond the scope of this 
paper. 

4. ATOMIC DEVS AND UML STATE DI- 
AGRAMS 

To map an atomic DEVS model into an UML state dia- 
gram, we need to map states, ports, transitions, and outputs. 

4.1. States 

In general, DEVS states are neither discrete nor finite, 
while UML states are always discrete and finite. To map a 
DEVS system onto an UML system, the DEVS state must be 



discretized. This can be done by rearranging and grouping 
DEVS state variables 7 = {7^} according to their kind. Dis- 
crete and finite variables can be collected in one subgroup, 
and countable and continuous variables — into another sub- 
group: 

7 = (7i, ■ • • ,7m,7m+i, • ■ • ,7n),l <m<n 

|range(7j)| < 00, 1 < j < m W 
|range(7j)| = 00, m < j < n 

Let's call the first group finite DEVS state variables, and 
the other group free DEVS state variables. 

For any feasible combination of values of finite DEVS 
state variables {74 11 < i < m}, a UML finite state can be 
constructed by simply enumerating this combination: Gj = 
®^Li 7i, where the details of the function (^) are not impor- 
tant as long as it always maps distinct combinations of finite 
DEVS state variables onto distinct UML states. 

All remaining DEVS free state variables {"/i\m < i < n} 
are mapped to UML pseudostate variables H = {hi\l < i < 
n — m} one-to-one. They become attributes of finite states 
and will be manipulated during DEVS state transitions. 

In the case of m = a DEVS model has no finite state 
variables, and partitioning (3) is not possible. The UML state 
diagram will have only one final state. This case is presented 
in [2]. 

On the other hand, when m — n, the DEVS model has 
no free variables. Every feasible combination of the DEVS 
state variables maps onto a UML finite state, and the UML 
model has no pseudostate variables. 

Not being a dynamic simulation language, UML does 
not enforce an explicit notion of time in all types of dia- 
grams. In particular, UML state diagrams do not have ex- 
plicit time. The simulation time has to be maintained im- 
plicitly, with model-wide variable f curr denoting the current 
simulation time. 

For the purpose of computing state transitions, many 
DEVS models depend on the time ej spent by the model in 
state <7i. To accommodate this need, we introduce another 
model-wide variable t e — the time of the most recent state 
transition. An "entry" action Wi can be added to every UML 
finite state that records the value of t e : 

def Wi (): 

te — ^curr 

At any given time, the value of a can be now computed 

as: 

{tcurr — t e Hi is the current state, , . 

+00 otherwise. 

4.2. Ports 

DEVS input and output ports are mapped to UML 
events one-to-one: 

Vtt, G (IP U OP) 3!pj G P. 

Input and output events are not distinguished in UML state 
diagrams. 



DEVS formalism does not specify whether the same port 
can be used as an input port and an output port (whether 
IP n OP = 0). We will assume that the DEVS ports are 
indeed unidirectional. This means that an event of a certain 
type can be only consumed or produced by a state diagram, 
but not both. 

4.3. External Transitions 

The heterogeneous structure of DEVS states and UML 
states produces heterogeneous structures of DEVS and UML 
state transitions. Among other things, a single DEVS ex- 
ternal transition function <5 ex t (ci> Si,Xj) = (irj n , Vj) has to 
generate both proper UML state transitions and their asso- 
ciated guard conditions and actions. 

The total state St; of a UML model is defined by the 
current UML finite state and the values of the pseudostate 
variables: 

S n = (si,H),\H\=n-m + l. 

The total state Ej of a DEVS model is defined by the 
values of all DEVS state variables: 

Hi = (7a, . . .,7m) = 7». 

To reflect a transition from a DEVS state at to another 
state aj, the corresponding UML model has to change from 
a UML state Si = /(7O to another UML state Sj — /(cr,) 
and also update the values of the pseudostate variables: 
Hj = /(7i). Here, f( x ) ■ DEVS_objects -> UML.objects 
is the polymorphic mapping function from the universe of 
DEVS objects to the universe of UML objects which has been 
partially defined above. 

Action a\ associated with a possible UML transition 
ti = (ijk\ = {si, Sj ,pk, gf ,af} from state s, to state Sj on event 
Pfe = /("""fT) would be responsible for updating the values of 
pseudostate variables H . It may depend on the original val- 
ues of the pseudostate variables, on the value of the event, 
and on ec 

def af (Hi, u k , e): 
Hj=zt{Hi, v k , e) 

Here, zf(H,v,e) is the explicit state update function: 

zf(H,u,e) = H' «-* 

e > OA (5) 

5ext f(Si,.ff),e, (7Tk\f)) = (sj,H') . 

This function may be undefined for some or all values of 
H , v, and e = ej. A condition for a possible UML transition 
is set Cf constructed in the following way: 

Ct = {(H,u,e) \{H,v,e) G dom(zf)}. (6) 

The UML transition exists if and only if the correspond- 
ing condition is not an empty set: 

UeT^Cf^ 0. 

Note that multiple transitions from Si to Sj may exist 
for different events Xk- In general, Si can be the same state 
as Sj (loopback transitions are possible). 



The guard condition gt is a functional representation of 
the condition set Cf: 



The guard condition gt is a functional representation of 
the condition set C\: 



9i(H, v,e) 



J true {H,v,e) G Cf , 
I false otherwise, 



(7) 



g\{H) 



true H G Cf, 
false otherwise, 



(10) 



where e for state Sj is defined by Eq. 4. The transition is 
"fired" if event pt occurs and gf(H,Uk,e) is true. 

4.4. Internal Transitions and Output Events 

Internal transitions and generation of output events are 
regulated by the internal transition function Si n t (o~i), the 
time advance function t a (en), and the output function A (en)- 
The three functions cooperate in the sense that the first func- 
tion computes the target state of the transition, the second 
schedules the transition, and the third generates an output 
event associated with the transition. DEVS models allow to 
output events only during internal transitions. 

As the external UML transitions, internal UML transi- 
tions need to advance the UML model to another state and 
to update the pseudostate variables. 

Action a\ associated with a possible UML transition 
ti = ujk) — {si, Sj , e, gi,a]} from state s» to state Sj on null 
event e would be responsible for updating the values of pseu- 
dostate variables H . It may depend on the original values of 
the pseudostate variables. 

Unlike an action associated with an external transition, 
a\ can generate output events. UML2.0 allows UML compo- 
nents to "send" events to any UML component M, including 
the component that sends the event ("self"), either immedi- 
ately, or later. Keyword "after" that is used to schedule an 
event in the future. Caret (") represents the send operation. 
For example, 'M.e after t means "send event e to component 
M after time t. n 

The function A (ffi) defines whether an output event is 
generated during the transition or not, and if yes, what is the 
type (port) of the event 7rf ut and its value Vi. The value of 
the event can be stored in the UML model as its attribute. 
By construction, the name of the output event and the name 
of the output port of an atomic DEVS model coincide: 

def a\ (Hi): 

(jrfVi)=A(ffO 

Hj=zt(Hi) 

Here, z\(H) is the explicit state update function for in- 
ternal transitions: 



zt(H) = H' ++5 int ((s i ,H)) = (s j ,H') 



(8) 



This function may be undefined for some or all values of 
H. A condition for a possible internal UML transition is set 
C\ constructed in the following way: 

Ct = {H\H G dom(4)}. (9) 

The internal UML transition exists if and only if the 
corresponding condition is not an empty set: 

ueT^c]^ 0. 

In general, Si can be the same state as Sj (internal loop- 
back transitions are possible). 



The time spent in DEVS state Oi before the transition is 
scheduled, is given by the function t a (&%)■ 

It is tempting to use the send/after apparatus to schedule 
the transition in the future. However, a transition is not 
an event and cannot be scheduled using "after" and "send" . 
Instead, we declare new timeout event a and schedule it at 
time icurr + t a ((si, Hi)) be redefining the entry action Wi of 

St&tiG S i . 

Event a becomes the trigger for the internal transition 
from state Si. 

A situation may occur when a timeout event has been 
scheduled, and an external transition is triggered by another 
(input) event. In this case, the pending timeout must be 
canceled. UML2.0 does not allow to recall scheduled events. 
Instead, a guard condition can be changed to make sure that 
obsolete timeouts do not trigger internal transitions. 

Let every UML state s; have local variable yt initialized 
to the reference to the most recently scheduled timeout event 
e; in the entry action: 

def Wi (): 

t e — ^curr 

%ji = ref(ei) 

~self.ei after t a ((si,Hi)) 

If the value of yi and the reference to the scheduled time- 
out a differ, the timeout event must be ignored. 

To summarize, an internal transition from state s; is 
scheduled when occurs and if (yi == ref(ei)) A g](H) is 
true. 



5. COUPLED DEVS AND UML COMPO- 
NENT DIAGRAMS 

DEVS coupled models and UML component diagrams 
have a very similar structure, which makes mapping DEVS 
models onto UML component diagrams rather straightfor- 
ward. 

5.1. Components 

A DEVS coupled model iV has only one top-level com- 
ponent and only one level of nesting. This corresponds to a 
UML component diagram N u with Tjv = {To} and such that 
VA/, G M u \ T N ,VMj G M u : (M», M 3 ) Q u . 

The top-level component To, therefore, represents the 
DEVS coupled model itself, and for each DEVS component 
A/ d G M there exists an UML component Mf G M U ,M? = 
f(M d ). 

5.2. Ports 

Both input ports IP and output ports OP of TV are 
mapped to the corresponding UML ports of the top-level 
component To with externally visible ports Pg. Let port 
Pi G IP carry input events of type Xi G X. Then for this port 
3pi = f(pi) = (t, ifc, d) G Pq : d = input At = Xi. Let port 



Pj £ OP carry output events of type yj £ Y. Then for this 
port 3p" = f(pj) = (t,ifc,d) £ Pq : d = output At — y 3 . 
Notice that input and output events are mapped to the port 
names implicitly. 

5.3. Connectors 

External DEVS coupling corresponds to external (del- 
egation) UML connectors. External input coupling of in- 
put port pi £ IP to an input port p" = f(pi) of compo- 
nent Md £ M is mapped to a delegation connector from the 
corresponding port of Tq to the corresponding port of Af": 
Vc, = ((JV.IPO, (d,IP di )) £ E IC ^ = ((T ,p 0j ), (M£,p H )) : 
Mfc = /(Af d ) Ap<y = /(IPi) Apw = /(IPdi)- Respectively, 
external output coupling of an output port p" = /(pi) of 
component Afd £ M to output port p, £ OP is mapped to a 
delegation connector from the corresponding port of Af" to 
the corresponding port of T U : Vc^ = ((d, OP di ), (N, OPj)) £ 
£oc3c? = ((Af?,pH),(T ,poi)) : Af£ = f(M d ) A p oj = 
/(OP 4 )Ap« = /(OP,«). 

Internal DEVS coupling corresponds to internal (assem- 
bly) UML connectors. Internal coupling of port pj = f(pi) 
of component Md £ M to port p" = f(pk) of component 
Me £ M is mapped to an assembly connector from the cor- 
responding port of Af" = /(Afd) to the corresponding port 
of Ml =/(Af e ). 

5.4. Selection function 

There is no feasible way of mapping the DEVS selec- 
tion function to a UML model. Fortunately, parallel DEVS 
models do not use this function at all. 

6. CONCLUSION AND FUTURE WORK 

In the paper, we proposed a mapping of discrete event 
specification (DEVS) models onto Unified Modeling language 
(UML) state and component diagrams. This diagrams are 
designed and optimized for computerized processing and 
are highly expressive, competitive, and widely used both 
in academia and industry. Successful automated DEVS-to- 
UML mapping techniques would enable seamless integration 
of the legacy of DEVS models into existing and emerging 
UML models. 

As the future step, we plan to consider UML2.0 com- 
posite structure diagrams as more suitable representations 
of DEVS coupled models. An automated translator from 
the DEVS domain into the UML domain would substantially 
simplify the transformation. Limiting the output to the Ex- 
ecutable UML is also considered. 
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